Modern wireless and wireline data communications networks employ packet data processing and exchanges at various layers within digital data communication's Open System Interconnection Reference Model (the OSI model). As would be understood by those skilled in the art, the OSI Model is an abstraction that defines conceptual, layered communications and computer network protocol design. At its core, the OSI model divides a network's communication architecture into seven distinct components, which include the following layers (from top to bottom): Application, Presentation, Session, Transport, Network, Data-Link, and Physical Layers. Generally, a particular OSI layer provides services to the layer above it and additionally the same OSI layer also receives services from the layer below it. Depending on where a given layer resides within an OSI stack, there may or may not be a layer above or below it with which the layer exchanges services.
In the context of a layered protocol stack, a unit of data specified in a given layer is commonly referred to as a protocol data unit (PDU). The PDU typically includes both payload and overhead (i.e., header information) data. A PDU may be referred to by other terms, such as a frame, a packet, a segment, a message, and so on . . . . In order to facilitate network communications, layered protocol stacks must facilitate transfer of PDU data amongst different portions (e.g., both wireless and wireline portions) of a data communications network. At each protocol layer, header information exists that can comprise a variety of data transfer information. Header data size generally remains constant for a given protocol layer, but it can also be variable. As data is passed to lower layers of the protocol stack, additional header information, specific to that layer can be added to the PDU. As data is passed to upper layers of the protocol stack, header information that is not used by the upper layers is generally removed from the PDU.
A PDU header may contain crucial data transfer information as well as instructions about data being carried in a particular PDU's payload. This information and these instructions may include, but are not limited to: a destination address (e.g., an IP address where a PDU is being routed through or delivered to), an originating address (e.g., an IP address where a PDU came from), PDU size information, synchronization information that allows a PDU to be compatible within an existing network infrastructure, a PDU sequence number that identifies which PDU a current PDU pertains to in a sequence of PDUs, a PDU protocol (with networks that carry many different types of information, the PDU protocol may define what type of PDU is being transmitted: e-mail data, webpage data, streaming video data, image data, etc.), encryption security data (encapsulating security payload information), etc.
Each PDU payload of a particular data transmission typically has a fixed-size PDU header attached to it before it is sent over a network communications link in a distributed data communications network (e.g., combined as a data packet). The PDU header is subsequently removed from the PDU payload at the receiving end of the network communications link so that sequenced payload data can be reassembled at a receiving device. In general, a PDU header represents a fixed communication link overhead that is required to ensure that PDU payload data is correctly routed to its delivery destination.
In many data communications systems where data packets are transmitted and routed amongst various network service provider devices (SPDs) and various subscriber computing devices (SCDs), communications link throughput may be restricted by a number of data packets that can be processed by a receiving SCD per unit of time (e.g., packets processed per second). This condition may be particularly detrimental in cellular data communications networks, where receiving SCDs (e.g., cellular telephones) are often designed with low cost processors that may not be capable of processing a maximum number of packets that a originating transmitter and/or intermediary transmitter is capable of sending to it.
As would be understood by those skilled in the Art, link throughput is generally defined as a rate of successful data communications delivery over a particular network communication channel per unit of time. This throughput is usually measured in bits per second (bps) or alternately in data packets per second. Some SCDs may only be able to process data at a maximum link throughput as long as an average packet size for a particular data communication session is sufficiently large enough. In scenarios where an average packet size for a data communications session is too small, either a transmitter or a receiver device may not be able to process a stream of data that arrives too quickly, due to device capability. Disadvantageously, this may result in data being lost during transmission. This lost data may detrimentally affect communications quality, and in accordance with the characteristics of some IP protocols, lost data may need to be retransmitted. This can negatively impact present and future network communication efficiency. Required retransmission can also lead to network congestion, particularly during peak data communications periods in portions of a data communications network experiencing increased levels of network traffic.
By way of example, assume a receiving SCD in a wireless data packet communications system is capable of processing 2000 Internet Protocol (IP) packets per second. If each packet contains 1500 bytes of IP data, then the maximum number of bits per second that the receiver would be capable of receiving would be defined by the following formula:2000 packets/sec×1500 bytes/packet×8 bits/byte=24 Mbits/sec
In contrast, if each packet were to only contain 100 bytes of IP data (100 bytes/packet) then the maximum number of bits per second that the receiver would be capable of receiving would be defined by the following formula:2000 packets/sec×100 bytes/packet×8 bits/byte=1.6 Mbits/sec
In this scenario, a transmitting device and a corresponding communications link may be capable of facilitating data transfer at rates much greater than 1.6 Mbits/sec (e.g., at rates consistent with Gigabit Ethernet: 1000 Mbs, or at rates consistent with the 802.11n standard: 108 Mbps, etc.). When sending side data transfer rates exceed receiving side processing capability, particularly with certain communications protocols (e.g., such as TCP/IP), lost data can lead to a rapid slowdown in throughput. This detrimental scenario could potentially be avoided if data packets were sent at a rate that was more compatible with a receiver SCD's processing capabilities. Alternatively, if a “connectionless” protocol, such as User Datagram Protocol (UDP), is utilized to send packets from the transmitter to the receiver, the high packet rate could cause transmitter PDU queues or receiver PDU queues to overflow. In this overflow scenario, a SCD that receives data packets too quickly may have design deficiencies that cause the SCD to drop significant amounts of data or to experience a software failure, requiring a reset (a hard boot) of the receiver device.
As would be understood by those skilled in the Art, UDP is an IP protocol commonly used for many different types of popular Internet communications. Networked SCD applications can utilize UDP to send messages on an IP based network without requiring prior communications routines to set up special transmission channels or data paths. UDP uses a simple transmission model without requiring node hand-shaking for guaranteed reliability, data packet ordering, or data integrity. UDP may provide unreliable service and it may assume that error checking and correction is either unnecessary or performed at the computer application level, thereby allowing UDP to avoid significant overhead associated with processing at the network interface level. Time-sensitive applications often use UDP because dropping packets may be a preferred option, compared to waiting for delayed packets, which may not always be an option in a certain real-time streaming data transfer scenarios. A few common network applications that may utilize UDP include: streaming media applications utilizing IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP), as well as online gaming applications.
In line with the above examples, assume a data service provider offers a 5 Mbps data service plan to one or more SCDs that are each capable of receiving and processing up to 2000 packets per second. As long as an average packet size for a particular data communications session is greater than:5Mbits/sec÷(8 bits/byte×2000 packets/sec)=312.5 bytes/packet
The service should theoretically operate without significant data transfer problems, however, if the average packet size drops below the 312.5 bytes/packet threshold and the transmitting device (e.g., a SCD or a SPD) attempts to maintain a 5 Mbps throughput, then data packets may be dropped at the receiving SCD, even though the data rate in bits per second is below the 5 Mbps threshold.
Further, as would be understood by those skilled in the Art, with a constant PDU payload throughput on a particular network communications link, the total PDU throughput (including fixed-size PDU header data) depends on an average PDU payload size. By way of example, if an average PDU payload size decreases on a network communications link, while the PDU payload throughput remains constant, then an actual link throughput will increase in proportion to the decrease in the average PDU size. Likewise, if an average PDU payload size increases on a network communications link, while PDU payload throughput remains constant, then an actual link throughput will decrease in proportion to the increase in the average PDU size. Due to the fact that an actual link throughput can drastically change with respect to variations in average PDU payload size (as the average PDU payload size decreases, while PDU payload throughput and header data size remain constant), there may be scenarios where actual link throughput is negatively impacted due to the nature of data communications that result in a relatively small average PDU payload data size (e.g., if the average PDU payload size is less than a designated multiple of the PDU header size, such as ten times the PDU header size).
Modern service providers may employ rate-limiting schemes that limit the PDU payload throughput in vacuum of the various data types that are being transferred across network communications links within portions of a larger data communications network. Further, present day service level agreements may not account for total PDU throughput, based on both payload and header size information, when allocating network resource limits to subscribers via various predetermined data-rate plans. Considering how different data types can affect the relationship of an average payload size compared with an average or constant header size can be very important for network resource planning considerations. For example, in a case where communications of a particular data type (e.g., streaming media types such as video and gaming data) results in a small average payload size, in relation to a constant PDU header size, a total throughput consumed on a communications link is substantially larger than the throughput of the PDU payload data alone. This additional link throughput may be much larger than a service provider anticipated when they drafted their service level agreements for regional network subscribers. Accordingly, service providers should account for more than just user generated traffic represented by PDU payload throughput.
Short-sighted network traffic planning can ultimately lead to periods of network congestion (data transfer loads that burden network capacity and throughput) between links in a larger data communications network. These overload periods can degrade a service provider network's Quality of Service (QOS) as well as network service subscribers' collective Quality of Experience (QOE) within a particular network, especially during peak data transfer periods. Some negative effects of poor traffic planning can lead to adversely affected network QOS and QOE metrics, which may result in: queuing delay, data loss, as well as blocking of new and existing network connections for certain network subscribers.
It would be beneficial to have improved systems and methods utilizing hybrid rate-limiting schemes that allow service providers to advantageously compensate for traffic types and receiving device capabilities. This could be facilitated by employing one or more data bit count rate-limiting mechanisms in combination with a packet count rate-limiting mechanism. It would be beneficial if the data bit count based rate-limiting mechanism(s) accounted for both traffic generated by a user (PDU payload only data bits), in combination with necessary traffic generated by total PDU data bits (relating to combined PDU header and payload data bits). By contemplating and accounting for these factors, service providers can mitigate situations where a significant amount of data being transferred may be lost due to deficiencies associated with receiving device capability, where device failures may occur when data transmission rates exceed device processing power, and where small average payload size data would unnecessarily burden actual link throughput. It would further be desirable to improve network resource allocation by practically enforcing hybrid rate-limiting schemes and by contractually enforcing more robust service level agreements that could affect network bandwidth maximization for a wide range of network SCDs transferring a variety different data types across portions of a distributed data communications network.